Equality comparison between two containers of mismatched types is not working because I can't get the SFINAE to compile... so comparing a flat_set against a vector, for instance, doesn't work.

Fortunately we only have flat_set used in operations? Otherwise I guess we need to add more types into GRAPHENE_OP_RESTRICTION_ARGUMENTS_VARIADIC.

The fee logic is very simple, just a flat op price plus a price per byte. I believe this structure is adequate, and its simplicity will significantly reduce the complexity of frontend development.

The front-end usually doesn't calculate fees by their own but simply calls get_required_fees API, the real work will still be done by the back end.

Equality comparison between two containers of mismatched types is not working because I can't get the SFINAE to compile... so comparing a flat_set against a vector, for instance, doesn't work.

Fortunately we only have flat_set used in operations? Otherwise I guess we need to add more types into GRAPHENE_OP_RESTRICTION_ARGUMENTS_VARIADIC.

Vectors are used in several operations. Mostly vector<char> though there are a few others. Comparing a vector to a flat_set is clumsy, so it doesn't need to work, but perhaps we should add some vectors to the legal restriction arguments...

@MichelSantos has brought up an interesting point: the current spec/implementation does not really provide a way to restrict that a container field have only values selected from a defined list. The logical way to do this would be to allow the in predicate (any in the spec) to operate on a container type field as well as a scalar type field, to say "all values in the field must be in the argument". This could be done for the not_in predicate (none in the spec) as well, to say "no value in the field may be in the argument".

With a slightly loose interpretation of the wording, the spec supports this. Shall I add this functionality to the implementation?

Changes requested so far have been applied.

Shall I add this functionality to the implementation?

I tend to leaving this for a later release. Unsure though. I guess it's a small change only, but OTOH I can't imagine where it'd be useful.

Shall I add this functionality to the implementation?

I tend to leaving this for a later release. Unsure though. I guess it's a small change only, but OTOH I can't imagine where it'd be useful.

It is fairly straightforward to add, yeah. Michel was attempting to test a case where someone wants to set a custom authority that can appoint feed producers for an asset from an authorized list. I'm not sure how useful that is in real life, but it's an illustrative example.

I've added the specializations, but I can remove them if they are not desired.

Awesome!

Yay!...this once lowly issue: #1061 led to this :)

Somewhat proud despite not actually having done much :D